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(54) Title: DIAGNOSTIC SYSTEM PARTICULARLY FOR AN ENGINE MANAGEMENT SYSTEM 
(57) Abstract 



A diagnostic system (10) particularly though not exclusively 
for use in an engine management system is provided for generating 
a diagnostic trouble code (DTC) to indicate the operational status 
of a component or sub-system which is being evaluated by the 
diagnostic system. The diagnostic system includes a diagnostic 
function module (DF Module) (20, 20’ t 20") for each DTC or a 
group, of related _DTCs associated with, a component or. sub-system 
The DF module including means (22) for executing an evaluation 
routine to evaluate the operational status of a component or sub- 
system to which the DTC of the specific DF module relates, and a 
diagnostic function scheduler (DF scheduler) (30) for determining 
which DF module may be allowed to execute an evaluation routine 
at a particular time. Each DF module (20, 20\ 20") includes 
means (22) for producing a ranking value dependent on the 
operating status of the component or sub-system being evaluated, 
a ranking value being generated each time an evaluation routine 
is performed; means (23) for processing and storing statistical 
results of the ranking values obtained over a number of evaluation 
routines; means (23) for evaluating the statistical results to produce 
evaluated data in the form of either an evaluated no-fault signal 
or an evaluated fault signal, and means (24) for transmitting the 
evaluated signals to the DF scheduler (30). 
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TITLE: Diagnostic system particularly for an engine 
management system 

TECHNICAL FIELD: 

The present invention relates to a diagnostic system, 
particularly for use in an engine management system, for 
generating a diagnostic trouble code ( DTC ) to indicate the 
operational status of a component or sub-system which is 
being evaluated by the diagnostic system. 

The invention further relates to a validator for use in a 
diagnostic system to determine the validity of a diagnostic 
trouble code (DTC) generated during an evaluation routine 
within the diagnostic system. 

The invention also relates to a data collector for use in 
a diagnostic system to collect and store data in the event 
that a fault arises in a component or sub-system monitored 
by the diagnostic system. 

The invention also relates to a scheduler for determining 

.the — order of execution .of ...a. pluralit y of ev aluation 

routines in a diagnostic system. 

The invention further relates to a DF module for executing 
an evaluation routine during a driving cycle to detect a 
fault in a component or sub-system in an electro-mechanical 
system such as an engine management system and to generate 
a diagnostic trouble code (DTC) to indicate the operational 
status of the component or sub-system. 

BACKGROUND OF THE INVENTION: 

In order to ensure that operators of electro-mechanical 
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equipment are made aware of any faults which may arise in 
electronic components of the equipment, self-diagnostic 
systems are employed to monitor the components or sub- 
systems and to communicate a warning to the operator should 
a fault be detected. Such a warning may be in the form of 
a malfunction indication lamp (MIL) which is illuminated on 
a control panel. 

In the vehicle industry, legislation now dictates that 
drivers of vehicles must be made aware of certain faults 
which may arise in the engine management system of the 
vehicle. For this purpose, self-diagnostic systems are 
employed to monitor the components or sub-systems in the 
engine management system and to communicate a warning to 
the driver should a fault be detected. Such a warning may 
be in the form of a malfunction indication lamp (MIL) which 
is illuminated on the vehicle dashboard. Depending on the 
severity of the fault, the driver may be instructed to 
visit a workshop immediately to have the fault rectified 
or, in the case of a minor fault, he may wait until the 
next scheduled visit to the workshop. 

For certain engine management systems, primarily those 
which affect exhaust emissions, legislation dictates how 
_ freq ^ ently and under what circumstances diagnostic checks 
are to be performed. Accordingly, standard dr iving~ cycles 
exist during which all diagnostic checks must be completed. 
Legislation also requires that, should certain faults be 
detected during two consecutive driving cycles, these 
faults be permanently recorded in a memory so that they may 
be later accessed in the workshop. 

Examples of engine management systems include an engine 
control module, an exhaust gas recirculation system, an 
evaporated fuel processing system, a secondary air system 
and a catalytic converter monitoring system. Further 
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components which require monitoring may include an engine 
coolant temperature sensor, a mass air flow meter sensor, 
an engine speed sensor, etc. Whilst the functioning of some 
components can be checked virtually independently of the 
operating conditions of the engine, many components and 
systems can only be checked when certain operating 

parameters prevail, e.g engine load, temperature, engine 
speed, etc. 

Accordingly, diagnostic systems have been developed which 
prioritize certain diagnostic checks over others . For 
example, a priority system is described in US-A-5 331 560 
m which certain diagnostic checks can be interrupted if 
operating conditions dictate that a diagnostic check can be 
performed on an engine management system for which the 
necessary operating parameters only rarely occur. Once the 
existing diagnostic check has been interrupted, the 
prioritized check can then be performed. 

Due to the interrelationship between many components and 
sub-systems making up the engine management system, if 
operating conditions are such that a diagnostic check may 
be performed on one component or sub-system, it is 
necessary to inhibit diagnostic checks on other components 
— or . sub-systems ..which _may... otherwise _af feat_the_validity~of — 
the result of the diagnostic check. For conventional 
diagnostic systems, this implies that if a component or 
sub system is added or deleted, the diagnostic system must 
be reprogrammed to ensure that the diagnostic system is 
aware of the effect of the new/deleted component or sub- 
system on the remainder of the engine management system. 
Naturally, the same problem arises when it is desired to 

implement the same diagnostic system in a different vehicle 
model . 



The above-mentioned 



interrelation between 



various 
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components and sub-systems further implies that should a 
fault be detected in one component, the effect of the fault 
may be reflected during diagnostic checks performed on 
several components or sub-systems. It is therefore 
desirable that means be available to accurately determine 
where the root cause of a fault lies and that no false 
fault signals be recorded. 

In order to assist the workshop or manufacturer in 
determining why a certain fault has arisen, it would be 
useful to be able to obtain information pertaining to the 
actual operating conditions of the vehicle from the time 
the fault arose up to the point when the fault was 

detected. This possibility has not been available up until 
now. 

SUMMARY OF THE INVENTION: 

It is therefore an object of the present invention to 
provide a diagnostic system for electro-mechanical systems, 
which diagnostic system can quickly identify faults, 
particularly in components or sub-systems relating to 
exhaust emissions, and which can easily be adapted for 
different installations. 



This object is achieved by a system according to claim 1. 



By grouping everything needed for each component or sub- 
system in a specific DF module to (i) perform an evaluation 
routine to detect a fault, (ii) store the evaluated results 
statistically, (iii) filter the evaluated results to decide 
when to create DTC-data and, preferably, (iv) decide in the 
case when reported valid when to store or erase the DTC- 
data and when to illuminate or extinguish the MIL, and by 
controlling the order of executing the evaluation routines 
of all the DF modules in the diagnostic system from a 
single DF scheduler, the diagnostic system can be quickly 
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adapted to changes of components or sub-systems since each 
DF module will be independent of the others. 

It is a further object of the invention to provide means 
which ensure that only the DTC which points out the root 
cause of a fault is indicated. 

This object is. achieved by the provision of a validator 
according to claim 10. 

It is yet another object of the present invention to 
provide means which, when a fault is detected, allows 
actual operating conditions of the vehicle to be recorded 
over a certain time before and up to the point at which the 
fault was detected, as well as allowing these conditions to 
be subsequently accessed. 

This object is achieved by a data collector according to 
claim 11 . 

It is a further object of the present invention to provide 
means for ensuring that evaluation routines are executed in 
an optimal order. 



Thi s_obje c t_ is achie ved by a schedu le r acco rd ing to c 1 aim. 
14. 

A further object of the present invention is to provide a 
DF module which contains sufficient means to be able to 
decide independently whether certain data is to be stored. 



This object is achieved by the DF module according to claim 
17. 

Preferred embodiments of the present invention are detailed 
in the dependent claims * 
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1 V 

BRIEF DESCRIPTION OF THE DRAWINGS: 

The invention will be described in greater detail in the 

following by way of example only and with reference to the 

attached drawings , in which 

Fig. 1 is a block diagram of a diagnostic system according 
to the present invention; 

Fig. 2 is a schematic representation of a diagnostic 
trouble code generated within the diagnostic system 
according to the present invention; 

Fig. 3 illustrates a possible scheduler table for use 
within a scheduler located in the diagnostic system 
according to the present invention; 

Fig. 4 illustrates a possible scheduler list for use in 
the diagnostic system according to the present 

invention; 

Fig. 5 illustrates a possible freeze frame table and 
extended freeze frame table for use within a DTC- 
data area located in the diagnostic system 
according to the present invention; 

Fig. 6 illustrates an example of a DTC-block Tor _ use^ in _ 

the diagnostic system according to the present 

invention; 

Fig. 7 is a schematic representation of a rotating buffer 
for use within a data collector located in the 

diagnostic system according to the present 
invention; 

Fig. 8 is an example of an extended freeze frame; 
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Fig. 9 illustrates a validator setup list and 
corresponding validator checklist, and 

Fig. 10 illustrates a flowchart for initialization of a 
validator checklist. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS: 

Although the present invention will be described in the 
following as a diagnostic system for use in an engine 
management system, it is to be understood that the 
invention may be suitably applied to any electro-mechanical 
system in which monitoring systems are incorporated. 



In Fig. 1, reference numeral 10 generally denotes a 
diagnostic system according to the present invention. The 
system includes a plurality of diagnostic function modules 
(hereinafter referred to as DF modules) 20, 20', 20", with 
each DF module serving a component or sub-system the 
operating status of which is to be evaluated. Examples of 
such components and sub-systems are an oxygen sensor in the 
exhaust pipe, an air leakage detection circuit, fuel 
injectors, an exhaust gas recirculation system, an engine 
coolant temperature sensor, a mass air flow sensor, an idle 
speed control valve, a manifold absolute pressure sensor, 
.-_an_e.ngine_sp.eed_. senspx,_a_qan i sjt e r_c.l o s.e_v.a l.ve.,_e.t c .-lit a 
manner which will be described later, each DF module 20, 
20', 20" is arranged to evaluate its associated 

component/sub-system and to generate a diagnostic trouble 
code (hereinafter referred to as DTC) which indicates the 
operational fault status of the component /sub-system. 

A preferred DTC format, generally denoted by reference 
numeral 200, is shown in Fig. 2 and consists of a 16 bit 
code divided into three parts. A first part 201 preferably 
consists of 8 bits and serves to indicate within which 
engine sub-system, for example the ignition system, fuel 
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and air metering system, etc, a fault resides. A second 
part 202 advantageously consists of 4 bits and serves to 
indicate within which component of the sub-system a fault 
resides. Finally, a third part 203, also of 4 bits, is used 
to indicate the type of fault that has an impact on other 
components /sub-systems, for example a slow response of an 
0 2 sensor, catalytic converter damage due to misfire, a 
stuck open valve, etc. 

Due to the fact that the diagnostic system according to the 
invention is arranged to evaluate the operational status of 
a plurality of components and sub-systems of an engine, and 
many of these components/sub-systems can only be evaluated 
when certain operating conditions are fulfilled, the system 
10 further includes a diagnostic function scheduler 
(hereinafter referred to as DF scheduler) 30. The purpose 
of the DF scheduler is to coordinate the priority between 
the different evaluation routines which are to be run by 
the respective DF modules so that it is ensured that as 
many evaluation routines as possible can be completed, 
dependent on the prevailing operating conditions, within a 
given time interval, at the same time that no two 
evaluation routines are allowed to take place 
simultaneously if there is a risk that this may result in 
an erroneous DTC being generated. An example of two 
evaluation routines which should not be performed 
simultaneously is a leakage detection check using a 
canister purge valve and monitoring of the catalytic 
conversion ratio. 

Furthermore, if a fault is detected by one DF module, the 
DF scheduler serves to stop evaluation routine^ that would 
otherwise be affected by the fault, i.e these stopped 
evaluation routines would otherwise be "deceived" into 
believing that a fault exists in their systems as well, 
even though there are no actual faults in these systems. 
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In the event that such an affected DF module performs its 
evaluation routine before the evaluation routine on the 
component/sub-system which possesses the actual fault is 
performed / then the affected DF module generates a DTC 
indicating a fault in the component/sub-system associated 
with that DF module. Accordingly, it is necessary that the 
diagnostic system 10 has access to sufficient information 
to be able to verify whether the DTC is valid or not. In 
other words, the system 10 must be able to determine 
whether the actual fault lies in the component/sub-system 
evaluated by the DF module which has provided the initial 
DTC, or whether the DF module has been "deceived" due to a 
present but not yet detected fault in another component/ 
sub-system . 

In order to provide the system 10 with information about 
vehicle operating conditions prior to the time when the DTC 
was generated, the system further includes a data collector 
module 40. In a manner which will be explained later, the 
data collector module is arranged to handle the creation of 
freeze frames and extended freeze frames . A freeze frame is 
a sample of a number of parameters which are specific for 
the actual DTC, such as the actual engine temperature and 
engine speed at the time the DTC was generated. An extended 

.freeze fram e co nta ins a numbe r of samples of a f ew_ 

parameters specific for the actual DTC from the time when 
the DTC was generated and backward in time. On the basis of 
this information, the data collector module 40 generates a 
DTC-block containing the DTC and this information. 

So that any DTC-blocks generated by the data collector 
module 40 can be stored, the system 10 is provided with a 
DTC-data area module 50. In a manner to be described later, 
when the DTC-data area module 50 receives a request from 
the data collector module 40 to save a DTC— block, it saves 
the block and sends a DTC-Saved 



response to the data 
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collector module. 

To determine whether the saved DTC-block is valid or not, 
i.e. if a fault actually exists or not in the 
component/sub-system checked by the DF module which 
generated the DTC, the system 10 is provided with a 
validator 60. The validator 60 receives the information 
that a not— val idated DTC— block has been saved from the DTC— 
data area module 50 and, by setting up a validator 
checklist (to be described), it is able to decide if the 
DTC-block is to be considered to be valid or not. 

If the validator 60 decides that a DTC-block is valid, then 
this implies that a component or system is malfunctioning. 
Depending on which component or system is affected, it may 
be desirable to inform the driver of the vehicle of the 
malfunction. Accordingly, the system 10 is provided with a 
malfunction indication lamp (hereinafter referred to as 
MIL) handler module 70 which can inform the driver of a 
malfunction by displaying an error sign or message on the 
dashboard of the vehicle. 

To permit the engine diagnostic system 10 to be able to 
communicate with external testers used by workshops, the 
system 10 advantageously includes an external communication 
handler (hereinafter referrecPto as ECH) module §6’ 

Finally, the system 10 is provided with a diagnostic system 
manager (hereinafter referred to as DSM) module 90 which is 
responsible for the starting of the diagnostic system once 
the ignition of the vehicle is turned on and for the 
stopping of the system when the engine control^ system has 
finished all other operations after the ignition has been 
turned off. This is accomplished by an interaction with 
both the diagnostic system and the engine control system, 
both situated within the engine control module of the 
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vehicle. 

In order to better understand the functioning of the 
diagnostic system 10 according to the present invention, 
each module or unit 20, 30, 40, 50 and 60 will be described 
in the following in greater detail. 

The DF module ?0 

As mentioned previously, each DF module 20, 20', 20" 
serves a component or sub-system whose operating status is 
to be evaluated. Accordingly, each DF module 20, 20', 20" 
is arranged to evaluate its associated component/sub— system 
and to generate a diagnostic trouble code (DTC) which 
indicates the operational status of the component /system. 
To achieve this, each DF module needs to be able to process 
all information needed for the evaluation of a 
malfunctioning component or sub-system such as a sensor, 
emission component, EVAP system, etc. 

To this end, and as is apparent from Fig. 1, each DF module 
20, 20 and 20" comprises a plurality of sub-modules 
including a DF interface 21, a physical diagnosis 
(hereinafter referred to as a PD) 22, a DF logger 23, a DF 
controller 24 and a DTC handler 25. 



The DF interface 2 1 is a DF sub— module which handles 
transfer of communication from and to DF sub-modules to 
other modules in the diagnostic system. Since the DTC 
generated by a particular DF module is unique to that 
module, the DTC is used as an identifier by other modules 
in the system for communicating with that particular DF 
module. Accordingly, the DF interface 21 is able to 
recognize all signals addressed to a DF module with the 
identifier that is related to the DF module in which the DF 
interface is located and assigns these signals to the 
correct DF sub-module. All signals sent from a DF sub- 
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module to the DF scheduler 30, the data collector 40, the 
DTC-data area 50, the validator 60, the MIL handler 70 or 
the ECH module 80 are transferred via the DF interface 21. 

The PD 22 is a DF sub-module which contains an evaluation 
routine for each DTC that is related to the particular DF 
module. The PD 22 is able to recognise when the engine 
operating conditions are fulfilled which will allow the DF- 
module 20 to evaluate its associated sub— system or 
component. Each time these conditions are met, the PD 22 
informs the DF controller 24 that it is possible to perform 
the evaluation routine. The PD waits for the DF controller 
to give permission before executing the evaluation routine. 



If, during an evaluation routine, the engine operating 
conditions change such that the conditions no longer 
coincide with those which are necessary to be able to 
perform the evaluation routine, the PD interrupts the 
routine. Similarly, if the DF controller 24 withdraws the 
permission to execute the evaluation routine, the PD 
interrupts the routine. 



In order to ascertain whether a possible fault is present, 
every time an evaluation routine is completed, the PD 22 
produces a ranking value as an indicator of the status of 
the checked component/sub-system . Preferably, each ranking 
value lies in the range from 1 to 255, with the value 128 
corresponding to a normal component or sub-system, for 
example the idle air adaptation value equal to a calibrated 
reference. The value 255 corresponds to a component or sub- 
system that is not working at all, for example the idle air 
adaptation value at maximum. Each component /sub-system is 
assigned a high fault limit and providing that the ranking 
value lies below the high limit, no fault will be indicated 
and an evaluated "no-fault" data signal is generated. 
Should the ranking value exceed the high limit, an 
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evaluated "fault" data signal is generated. Each time the 
evaluation routine is completed, the evaluated data signal 
is sent to the DF controller 24 and the ranking value is 
sent to the DF logger 23. 

The DF logger 23 is a DF sub-module that receives the 
ranking values and uses the highest of a specific number of 
ranking values to be processed statistically and the 
results are stored for use as information for the workshop. 

The DF controller 24 is a DF sub-module that controls the 
PD 22. Thus, when the PD informs the DF controller that it 
is possible to run the evaluation routine, a response is 
sent to the DF scheduler that the evaluation routine is 
inhibited. When the DF scheduler 30 sends a response that 
the evaluation routine may be performed, the DF controller 
24 permits the PD to run the routine. If the DF scheduler 
30 sends a request to inhibit the evaluation routine, the 
DF controller withdraws the permission to run the 
evaluation routine and when the evaluation routine has 
stopped, it sends an "inhibited" response to the DF 
scheduler. 

The DF controller 24 also receives all evaluated data 
Aignals__andinfprms_the_DF__scheduler_^0„of_anyLjchange__in_ 
status of the evaluated data signals defined as the latest 
evaluated data signal. The DF controller demands a 
consecutive number of evaluated "fault" data signals to be 
generated before it produces a controlled "fault" data 
signal. The actual number of consecutive signals required 
to bring about this change in condition is specific for 
each DTC that is to be generated. At ignition, the 
controlled data signal is set to "not-done" and at the 
first evaluated "no-fault" data signal, the controlled data 
signal is set to "no-fault". 
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Once the DF controller 24 produces a controlled "fault" 
data signal, it sends a request to the data collector 
module 40 to create DTC data. Once set, it is not possible 
to change the controlled "fault" data signal for the 
remainder of the driving cycle (until ignition off). 

The DTC handler 25 is a DF sub-module that is responsible 
for taking decisions after the diagnostic system 10 has 
validated a DTC-block as being valid. Its functions include 
deciding when to store the DTC-block permanently, sending 
a request to illuminate or extinguish the malfunction 
indication lamp in the MIL handler module 70 and deciding 
when to erase the DTC-block if the fault is no longer 
detected . 

DF scheduler module 30 

The DF scheduler module 30 handles the scheduling of 
evaluation routines. The DF scheduler module 30 receives 
requests to run evaluation routines from the DF modules 20, 
20 , 20 and decides in which order these evaluation 
routines shall be performed, taking into account whether 
any evaluated "fault" data signals are present, the time 
elapsed since the engine was started and the relative 
priority between the evaluation routines which have been 
requested. 



The DF scheduler module 30 takes into account any latest 
evaluated data which it receives from the DF modules and 
decides whether this evaluated data implies that certain 
evaluation routines affected by the fault should be 
inhibited. The DF scheduler also takes into account whether 
a DF module informs the DF scheduler module that an 
evaluation routine has been stopped because the conditions 
for running the evaluation routine are no longer fulfilled, 
or inhibited on request from the DF scheduler or due to DF 
scheduler not yet having sent the run response. 
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In order to fulfil its requirements, the DF scheduler 
module 30 requires access to information relating to what 
has to be done for each evaluation routine. This 
information may be contained in a scheduler table. An 
example of a possible scheduler table is shown in Fig. 3. 
The scheduler table contains all the evaluation routines 
for the diagnostic system and preferably specifies: 

the delay time before initiating the evaluation 
routine that has been requested to run, this time being 
dependent on the latest evaluated data received from the 
respective DF module; 

the priority level of all evaluation routines 
dedicated to certain specified priority groups so that the 
DF scheduler module can determine which of the requested to 
run routines has priority within each priority group, and 

which other evaluation routines to inhibit should 
the latest evaluated data from a DF module indicate a 
fault . 

In order to function effectively, the DF scheduler module 
also needs information concerning the current status of the 
evaluation routines in the diagnostic system. This 
information is provided by a scheduler list. With reference 
to Fig. 4, the scheduler list contains four sub-lists, 

namely. — an — inhibited — list., — a— running— ...list., a__latest _ 

evaluated data list and a to-be-handled list. 

The inhibited list indicates which evaluation routines have 
requested the opportunity to run but which are not 
permitted to run. Flags in this list are set for the 
evaluation routines that have reported that they are 
inhibited and reset for the evaluation routines that have 
indicated that they have ceased due to the physical 
conditions within the DF module or that have been turned 
off by the DF scheduler module. 
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The running list, as the name implies, indicates which 
evaluation routines are presently running. Flags in the 
running list are set for those evaluation routines which 
the DF scheduler module has allowed to commence running, 
and reset for the evaluation routines which are reported to 

be stopped, inhibited or turned off by the related DF 
modules . 

The latest-evaluated-data list indicates the current status 
of the evaluated data for each evaluation. Flags in this 
list are set for each evaluation routine that has sent a 
latest evaluated "fault" data signal, and reset for each 
evaluation routine that has sent a latest evaluated "no- 
fault" data signal. 

The to-be-handled list is used by the DF scheduler module 
as a working list to keep track of which evaluation 
routines remain to be handled because of priority, time and 
evaluated "fault" data signals. Each time the DF scheduler 
has finished processing the priority handler 35, the flags 
that remain "set" in the to-be-handled list are indications 
that the associated evaluations should be running, and 
flags that are "reset" are indications that the associated 
evaluations should be stopped or inhibited. 



To execute the required functions'" and' as is apparent from 
Fig. 1, the DF scheduler consists of a number of sub- 
modules including a DFS interface 31, a DFS controller 32, 
an inhibit handler 33, a time handler 34 and a priority 
handler 35 . 

All signals that are sent from DF modules 20, 2CL' , 20"' and 
the ECH module 80 to the DF scheduler module 30 are 
xdentif ied in the DFS interface 31 and transferred to the 
correct DF scheduler sub-modules. All signals that are sent 
from the DF scheduler sub-modules to the DF modules and the 
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ECH module are transferred via the DFS interface 31. 



All signals sent to the DF scheduler module 30 are checked 
by the DFS controller 32. The DFS controller updates the 
inhibited list, the running list and the latest evaluated 
data list for signals sent from the DF modules 20, 20', 
20 to the DF scheduler module 30. If any of the three 
lists has been updated, the DFS controller 32 acts as 
follows : 



10 



15 



20 



25 



30 



Copy the inhibited list and running list into the 
to-be-handled list. 

Start the inhibit handler 33. 

When the inhibit handler is finished, start the time 
handler 34 . 

When the time handler is finished, start the 
priority handler 35. 

When the priority handler is finished, perform a 
"stop routine", i.e. the DFS controller 32 sends inhibit 
requests to the evaluation routines that are running 
according to the running list (flags are set) but should 
not be running according to the to-be-handled list (flags 
are rese t) , and sets the flags in the inhibited list as an 
indication that the DF scheduler has requested these 
evaluations to be inhibited. 

When fi n ished with t he "sto p r ou t ine " , a "s tart 

routine" is performed, i.e. the DFS controller sends a run 
response to each of the evaluations that should be running 
according to the to-be-handled list and is each associated 
to a priority group according to the scheduler table in 
which no other evaluations are running according to the 
running list. For each run response sent, the DFS 
controller sets the corresponding flag in the running list. 

When finished, check if there is any signal which 
has been sent to the DF scheduler and if so start to work 
again. 



35 
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When a request to stop all evaluation routines is sent from 
the ECH module 80, the DFS controller 32 acts as follows: 

Clear the to-be-handled list and start to work 
(inhibit requests will be sent to all evaluation routines 
that are running) . 

When finished, update the latest evaluated data 
list, the running list and the inhibited list according to 
all signals sent to the DF scheduler but do not start to 
work as in normal operation. 

When all flags in the running list are reset, send 
the response that all evaluation routines have been stopped 
to the ECH module 80. 

Wait only for a request to resume normal operation 
from the ECH module 80. 

When the request to resume normal operation is 
received, copy the to-be-handled list and start to work as 
normal . 

When a request to turn off all evaluation routines is 
received from the diagnostic system manager (DSM) module 
90, the DFS controller 32 acts as follows: 

Send turn off requests to all evaluation routines. 

Update the latest evaluated data list, the running 
list and the requested-to-run list according to all signals 
sent to the DF scheduler. 

When all flags in ther mining Fist - and "inhibited ~ 
list are reset, send a response to the DSM module 90 that 
all evaluation routines have been turned off. 

Wait only for a general response signal from the DSM 
module 90 to start the diagnostic system 10 before starting 
to work as normal again. No action while waiting. 

The inhibit handler 33 acts only on a start request 
received from the DFS controller 32. The inhibit handler 33 
first checks the latest evaluated data list to determine 
which evaluation routines have generated latest evaluated 
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"fault" data signals. For those evaluation routines which 
have generated such signals, the inhibit handler 33 checks 
the scheduler table (Fig. 3) to determine which evaluation 
routines to inhibit due to reported faults . The inhibit 
handler 33 resets the flags in the to-be-handled list that 
correspond to the evaluation routines to be inhibited. When 
finished, the inhibit handler sends a "finished" signal to 
the DFS controller 32. 

The time handler 34 acts only on a request to start from 
the DFS controller 32. Furthermore, the time handler 34 
needs information about the time elapsed since engine start 
which it retrieves from a time after engine start timer. 

The time handler 3 4 first checks the to-be-handled list to 
determine which evaluation routines to inhibit due to 
lapsed time after engine start. For each flag that is set 
in the to-be-handled list, the time handler 34 checks the 
latest evaluated data list to determine whether the 
corresponding evaluation routine has latest evaluated data 
as "no-fault" or "fault". 

If the latest evaluated data indicates "no— fault", the time 
handler 34 checks whether the time after engine start timer 

J^.-.exceeded,_the_^g.lay- time at. no- fault i n the s cheduler- 
table (Fig. 3). 

If the latest evaluated data indicates "fault", the time 
handler 34 checks whether the time after engine start timer 

has exceeded the delay time at fault in the scheduler 
table. 

The time handler 34 resets the flags in the to-be-handled 
list for the evaluation routines where the time after 
engine start timer has not exceeded the delay time. 
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When finished, the time handler 34 sends a"finished" 
response to the DFS controller 32. 

The priority handler 35 acts only on a request to start 
from the DFS controller 32. The priority handler checks the 
to-be-handled list to ascertain which evaluation routines 
are to be handled. Using this list and the scheduler table, 
the priority handler 35 is able to determine which of the 
evaluation routines to be handled are in the same priority 
group, starting with priority group number 1 in the 
scheduler table (e.g. X) (Fig. 3). The priority handler 
resets the corresponding flag in the to-be-handled list for 
the evaluation routines that have lower priority levels 
than the evaluation routine that is to be handled and which 
has the highest priority level within the priority group. 

When finished with the first priority group, the priority 
handler 35 continues with priority group number 2 (e.g. Y) 
and so on until all priority groups have been checked. 

If an evaluation routine is assigned more than one priority 
group, it is handled as a part of each priority group. The 
level is then used individually in each priority 

group . 



The normal operation of the DF scheduler module 30, i.e 
with no handling of ECH or DSM requests, is explained in 
the following in the form of a flowchart. 

All responses that evaluation routines have stopped, 
inhibited or have been turned off and responses that the 
latest evaluated data signal has changed to or from "fault” 

are handled by the DF scheduler sub-modules in a defined 
order: 



Upon the response signal that an evaluation is 



1 . 
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6 . 
30 

7. 

8 . 

35 



inhibited, the DFS controller 32 checks the 
corresponding flag in the inhibited list and the 
running list. If not set in the inhibited list and 
not set in the running list, the DFS controller 
sets the bit in the inhibited list. 

If set in the inhibited list and not set in the 
running list, the DFS controller resets the bit in 
the running list. 

Upon the response signal that an evaluation is 
stopped or has been turned off, the DFS controller 
resets the corresponding flag in the inhibited list 
and the running list. 

At the response that a latest evaluated data has 
changed to or from "fault", the DFS controller 
updates the latest evaluated data list. 

In the event of any signal above, the DFS 
controller 32 adds the contents from the inhibited 
list to the content of the running list and stores 
the result in the to-be-handled list. 

The DFS controller 32 then starts the inhibit 
handler 33. 

The inhibit handler 33 uses the to-be-handled list, 
the latest evaluated data list and the scheduler 
table to decide which evaluation routines to 

inhibit,. . due ._to.-la.test evaluated "f a n it" d ata. 

The inhibit handler 33 resets the flags in the to- 
be-handled list corresponding to the evaluation 
routines that are to be inhibited. 

The inhibit handler informs the DFS controller 32 
when it has completed the above. 

The DFS controller now starts the time handler 34 . 
The time handler uses the to-be-handled list, the 
latest evaluated data list and the scheduler table 
to decide which evaluation routines are to be 
inhibited due to elapsed time after engine start. 

The time handler 34 resets the flags in the to-be- 
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10 . 



11 . 

12 . 



13. 



14. 

15. 



16. 



17 . 



handled list corresponding to the evaluation 
routines that are to be inhibited. 

The time handler 34 informs the DFS controller 32 
when it has completed the above. 

Thereafter, the DFS controller 32 starts the 
priority handler 35. 

The priority handler uses the to-be-handled list 
and the scheduler table to decide which evaluation 
routines are to be inhibited due to priority be- 
tween the evaluation routines . 

The priority handler 35 resets the flags in the to- 
be-handled list corresponding to the evaluation 
routines that are to be inhibited. 

The priority handler informs the DFS controller 32 
when it has completed the above. 

The to-be-handled list now shows which evaluation 
routines should be running at this time (flags are 
set) and which routines should not be running 
(flags are reset). 

The DFS controller compares this list with the 
running list. 

Stop routine: The DFS controller 32 sends inhibit 
requests to the evaluation routines that are 
running according to the running list (flags are 
set) but should not be running according to the to- 
be-handled' fist (flags are reset), and sets ^the 
flags in the inhibited list as an indication that 
the DF scheduler has requested these evaluations to 
be inhibited. 

Start routine: The DFS controller sends a run 
response to each of the evaluations that should be 
running according to the to-be-handled^list , with 
each evaluation that should be running being 
associated to a priority group according to the 
scheduler table in which no other evaluations are 
running according to the running list. 
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For each run response sent, the DFS controller sets 
the corresponding flag in the running list. 

This completes the normal operation of the DFS scheduler 
module 30 . 

The data c ollector module 40 

On request from a DF module 20, 20', 20" to create DTC- 
data, the data collector module 40 is arranged to perform 
the following functions: 

Create a freeze frame (hereinafter referred to as 
FRZF) with DTC specific data. 

Combine the FRZF with certain information to form 
a DTC-block . 

Create an extended FRZF (measurement over time) with 
DTC specific data. 

Send the DTC— data (DTC-block and extended FRZF) to 
the DTC data area module 50. 

Advantageously, the data collector module 40 can also act 
as an internal flight recorder on request from the ECH 
module 80. 

In order to fulfil these requirements, the data collector 

Jnodule — 40 — requires — information .concerning the specific 

parameters for each evaluation routine which is performed 
in the DF modules 20, 20 , 20 '. This information is 

provided in a FRZF table and an extended FRZF table. An 
example of a FRZF table and an extended FRZF table is shown 
in Fig. 5. Each number in the tables denotes a particular 
parameter. 

As mentioned above, the data collector module 40 generates 
a DTC-block. A DTC-block is a data block that contains 
information in the form of parameters pertaining to the 
operating conditions at the time that the DTC was 
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generated. An example of a possible DTC-block is 
illustrated in Fig. 6. Thus, the DTC-block consists of 
certain DTC specific information ( DTC, latest and initial 
DTC-subcode and FRZF delay time) together with the FRZF and 
finally a pointer to the extended FRZF. 

To be able to create an extended FRZF, which is a 
measurement over time of DTC relevant data, the data 
collector module 40 is provided with a circular memory in 
the form of a rotating buffer. As shown in Fig. 7, the 
rotating buffer is generally denoted by reference numeral 
110 and is in the form of a drum 111 divided into, in the 
illustrated example, four different time bases 112, 113 

114, 115 resp. 

An example of an extended freeze frame is shown in Fig. 8. 

A global data area, denoted by reference number 120 in Fig. 
1, is positioned externally of the diagnostic system 10 in 
the engine control system part of the engine control module 
and contains current information on values for all 
parameters for all evaluation routines. Each parameter is 
identifiable by a unique identification number in the 
global data area 120 and is allocated one of the time bases 
112, 1 13, 11 4, 115. Th e rot atin g buf fer 110 is updated each 
time any time base expires wit h^pa rame'ter _ values _ a sso ci a ted’ 
with the expired time base copied over from the global data 
area 120 and these parameters are stored in their 
respective time base. A pointer 116 , 117, 118, 119 to 
indicate the latest sample to be copied over is placed in 
front of the latest sample in each time base. When a time 
base of the rotating buffer 110 is full, the old.est sample 
is written over in that time base. In this manner, the 
rotating buffer 110 forms a circular memory with several 

time bases, each with equal memory depth but with specific 
time depth. 
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In order to generate DTC-data which will subsequently be 
forwarded to the DTC data area module 50 and to handle 
requests sent from the ECH module, the function of the data 
collector module 40 is divided into sub-modules, i.e a DC 
interface 41, DC controller 42, FRZF collector 43, extended 
FRZF collector 44 and a buffer handler 45. 

All signals that are sent from the DF modules 20, 20", 20"" 
and the ECH module 80 to the data collector module 40 are 
identified by the DC interface 41 and transferred to the 
correct data collector sub-modules. All signals sent from 
the data collector sub-modules to the DTC data area module 
50 and the ECH module 80 are transferred via the DC 
interface 41. 

Upon receipt of a request from a DF module 20, 20", 20'" to 
crea te DTC-data, the DC controller 42 requests the FRZF 
collector 4 3 to create a FRZF. Upon receipt of this 
request, the FRZF collector 43 checks the FRZF table (Fig. 
5) to determine which parameters specific for this DTC are 
to be copied over from the global data area 120. The FRZF 
collector proceeds to copy the parameters from the global 
data area and places them in the order specified by the 
FRZF table. When finished, the FRZF collector informs the 
DC contrpller 42 that the J_RZF _has _been ^rea ted. 

When the FRZF collector 43 has informed the DC controller 
42 that the FRZF has been created, the DC controller asks 
the extended FRZF collector 44 to create an extended FRZF. 

Upon receipt of this request, the extended FRZF collector 
44 performs the following acts: 

Stop the rotating buffer by sending a stop request 
to the buffer handler 45. 

Create an empty extended FRZF of correct size, the 
empty extended FRZF including parameter identification 




WO 97/13064 



PCT/SE96/0 1 244 



26 

numbers specified by the extended FRZF table. 

Upon receipt of confirmation that the rotating 
buffer has been stopped, copy over all the parameter values 
corresponding to the identification numbers in the extended 
FRZF that match the identification numbers specified in the 
rotating buffer table from the rotating buffer. 

the rotating buffer by sending a start request 
to the buffer handler 45. 

Send a response to the DC controller 42 that the 
extended FRZF has been created. 

Using i.a. information provided in the FRZF and the 
extended FRZF, the DC controller 42 creates DTC-data in the 
form of a DTC-block (see Fig. 6) modified to take account 
of the extended FRZF. 



Once the DTC-data has been created, the DC controller 42 
sends a request to the DTC-data area module 50 to save the 
DTC data. 



After sending the request, the DC controller 42 waits for 
confirmation from the DTC-data area module that the DTC- 
data has been saved before acting on any new request to 
create DTC-data. 

The DTC-data area module SO 

The DTC-data area module 50 is divided into four sub- 
modules, namely a DA interface 51, a DTC-block area 52, an 
extended FRZF area 53 and a DA controller 54. 



All signals that are sent to the DTC-data area module 50 
from the ECH module 80, the data collector module 40, the 
validator 60 and the DF modules 20, 20', 20" are 
identified by the DA interface 51 and transferred to the 
correct DTC-data area sub-module. All signals sent from the 
DTC-data area sub-modules to the validator 60 and the data 
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collector module 40 are transferred via the DA interface 
51. 



The DTC-block area 52 is used for storing the DTC-blocks. 
The number of DTC-blocks which can be stored in this area 
var: *- es f rom application to application, but a typical 
number is ten. The DTC-block area 52 is always capable of 
storing a predetermined maximum number of DTC-blocks plus 
one. The additional one represents a temporary space which 
is used to buffer the incoming data from the data collector 
module 40. The DTC-block area 52 uses a free list to keep 
track of the free DTC-blocks, and a temporary pointer to 
keep track of the temporary space. 

The extended FRZF area 53 is used for the storage of the 
extended FRZFs . The extended FRZF area 53 is always capable 
of storing a predetermined maximum number of extended FRZFs 
plus one. The additional one represents a temporary space 
which is used to buffer the incoming data from the data 
collector module 40. The extended FRZF area 53 uses a free 
list to keep track of the free extended FRZFs, and a 
temporary pointer to keep track of the temporary space . 

The DA controller 54 controls the DTC-block 52 and the 

__e.xtended_F.RZE_. area — 5.3 It — receives — a — DTC-block -and an 

extended FRZF via the DA interface 51 from the data 
collector module 40 and the DTC-block and extended FRZF are 
saved in the applicable data areas. 

When the DA controller 54 receives a request from the data 
collector module 40 to save DTC-data, the DA controller 
saves the DTC-block and associated extended FRZF and, when 
this is done, informs the validator module 60 that a not- 
validated DTC-block has been saved and waits for an 
acknowledge response or any request from the validator. If 
the validator sends an acknowledge response, the DA 
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controller informs the data collector module 40 that the 
DTC-data has been saved. 



If the related DF module sends an acknowledge response, the 
DA controller informs the data collector module 40 that the 
DTC-data has been saved. 

When requested by the validator module 60 to change a DTC- 
block status from not-validated to valid, or to erase a 
not-validated or valid DTC-block, the DA controller 54 does 
so and informs the related DF module if a valid DTC-block 
has been erased and waits for an acknowledge response or 
any request from the related DF module. 

When requested by a DF module to change a DTC-block status 
from valid to stored, or to erase a valid or stored DTC- 
block, the DA controller does so and informs the validator 

module 60 that a valid or stored DTC-block has been stored 
or erased. 

If, after sending a response that the DTC-data has been 
saved, the available space is not enough for the next DTC- 
block, i.e. no temporary space is free, the DA controller 
54 erases the DTC-block and associated extended FRZF having 
lowes t priority and informs th e v alidator module 60 and 
related DF module 20, 20', 20" that the particular DTC- 
block has been erased. If there is only not enough space 
for the next extended FRZF, the DA controller erases the 
extended FRZF having lowest priority and erases the link 
between the erased extended FRZF and the associated DTC- 
block but does not send any information about the event. 

At the request to erase all DTCs sent from the ECH module 
80, the DA controller 54 erases all DTC-blocks and, for 
each DTC-block erased, it informs the validator 60 
related DF module. 



and 
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The validator module fin 

The purpose of the validator module 6 0 is to determine the 
root cause of a fault. In other words, it is possible that, 
say, four DTC-blocks with extended FRZFs are generated by 
the data collector module 40, though in fact only one of 
the DTC-blocks is the true indicator of the fault. This is 
because the fault is deceiving the other affected 
evaluation routines so that erroneous controlled " fault" 
signals are sent from the affected DF modules to the data 
collector module 40. The validator therefore examines each 
of the four DTC-blocks (with associated extended FRZFs) to 

determine in which component or system the actual fault 
lies . 

Thus, when the validator module 60 is informed by the DTC- 
data area module 50 that a saved DTC-block is present, the 
validator sets up a checklist that contains all possible 
root cause evaluation routines that have to be performed 
and reported with controlled data as "no fault" before 
validating the correct DTC, i.e pointing out the DTC-block 
that is the root cause of the fault. The content of the 
validator checklist is stored at ignition off, i.e. the 
validation is independent of ignition on/off. 

_ Vay.dator_. setup-lists .-_are._used._to-_set._up —and initiate- — 

checklists. Each setup-list contains the DTC-to-validate 
and a specification of which evaluations have to be checked 
before validation of the DTC-to-validate. A validator setup 

list and corresponding validator checklist is illustrated 
in Fig. 9. 

A checklist is set up according to its set-up list in the 
following manner. 

When the validator module 60 is informed by the DTC-data 
area module 50 that a DTC-block has been saved, the 
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validator module searches the setup-lists for a DTC-to- 
validate that corresponds to the DTC in the DTC-block. If 
the DTC is not found in any of the DTC-to-validate 
positions in any of the setup-lists, the validator 
immediately makes the DTC-block valid by requesting the 
DTC-data area module 50 to change status on the DTC-block 
from not validated to valid. 

If the DTC is found, the validator setup-list containing 
the matching DTC-to-validate is used to set up a validator 
checklist specific for this DTC. The checklist comprises 
the following items : 

A header specifying the DTC being validated (this 
links the checklist to its setup-list) . 

A time stamp (elapsed realtime read from the global 
data area 120) . 

Flags indicating the status for each evaluation-to- 
check in the validator setup list, a flag being set for 
controlled no-fault and reset as long as controlled no- 
fault has not been reported. The evaluation-to-check linked 
to each flag is defined in the setup-list. 

A validator setup list that has a validator checklist 
lxnked to it is, in the following, termed an active 
validator setup-list. 



The validator checklists are updated only on request sent 
from the DSM module 90 at the end of each driving cycle. In 
the update procedure, the validator module requests 
controlled data from each DF module 20, 20', 20" defined 
in the active validator setup-list. Each DF-module responds 
with its current controlled data state,, i.e. not 
controlled, controlled fault or controlled no-fault. The 
response "controlled no-fault" sets a corresponding flag in 
the validator checklist. The responses "not controlled" and 
"controlled fault" reset the corresponding flag in the 
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When all the flags in the validator checklist are set, the 
DTC-block associated with the DTC-to-validate is decided to 
h® valid and the validator module 60 sends a signal to the 
DTC-data area module requesting a change of the DTC-block 
status from not-validated to valid. The DTC-data area 
module 50 changes the status and then sends a signal to the 

applicable DF module that a DTC-block status has changed to 
valid . 

As illustrated in Fig. 10, when the validator module 60 
receives a second not-validated DTC-block saved signal 
(Checklist A) from the DTC-data area module that 
corresponds to an evaluation-to-check in an active 
validator setup-list with associated validator checklist 
(Checklist B) , the DTC-block that generated that active 
validator checklist is not considered to be the root cause. 
Such DTC-block and validator checklist (Checklist B) are 
therefore erased. This is achieved by sending a signal to 
the DTC-data area module requesting the DTC-block relating 
to the header in the validator checklist to be erased. Upon 
the response that the DTC-block has been erased, the 
validator erases the related validator checklist. A new 
...validator- checklist, is. set up. for -the.other. DTC-block that- 
caused these events . 

When the validator module 60 receives a signal from the 
DTC-data area module 50 that a DTC-block status has been 
changed from valid to stored, the corresponding validator 
checklist is erased. 



To ensure the relevance of the information in the validator 
module 60, a validator checklist reset function is 
implemented. The reset function resets all the flags when 
the validator checklist is older than a predetermined 
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period of time, for example at least 168 hours. 

Overall normal operation of the diagnostic system 10 when 
no fault is present 

The overall normal operation to run the different 
evaluations with correct system (i.e. no fault) is 
described below: 

At the signal to start the diagnostic system sent from the 
DSM module 90, each DF module will; as soon as the physical 
conditions are fulfilled for running its evaluation, send 
the information that its evaluation is inhibited due to 
priority to the DF scheduler module 30. 

When the DF scheduler module receives this information, it 
establishes the order of priority for the evaluations that 
are inhibited due to priority in addition to the 
evaluations that are running (none so far in the present 
scenario) and sends run responses to the related DF modules 
that contain evaluations that are permitted to run. 

The DF modules that receive the run responses from the DF 
scheduler module will now run their evaluations to thereby 
produce evaluated data. The evaluated data is used to 
determine whether or not there is a fault present in the 
checked component/sub-system and also to decide whether or 
not DTC-data is to be created. 

If an evaluation routine is interrupted due to changes in 
its physical conditions (e.g. engine speed), or is finished 
for the rest of the driving cycle, the related DF module 
sends a response to the DF scheduler module that the 
evaluation has stopped. 



When the DF scheduler module receives a response that an 
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evaluation has been stopped, the DF scheduler module 
establishes the order of priority for the evaluations that 
are inhibited due to priority in addition to the 
evaluations that are still running and, if permitted, sends 
run responses to the related DF modules that contain 
evaluations that are now no longer to be inhibited due to 
priority. This is repeated until the DSM module 90 sends a 
request signal. to turn off all evaluations, i.e. to stop 
the diagnostic system. 

This completes the overall normal operation for the 
diagnostic system when no fault is present. 

O verall — normal operation when one or more faults 3rP 

present in t he diagnostic system 

The overall normal operation to inhibit affected 
evaluations and to store the correct DTC (together with MIL 
illumination) in the diagnostic system 10 with one or 
several faults present is described in the following: 



If, during the overall operation described above for when 
no fault is present, an evaluation routine in a DF module 
detects a fault and generates evaluated data as "fault", 
- then the related DF module sends latest evaluated _data„ as. 
"fault" to the DF scheduler module 30. 



When the DF scheduler module receives a latest evaluated 
data as "fault", it firstly inhibits the evaluations that 
are affected by this fault and then establishes an order of 
priority between the remaining evaluations that are not 
affected by the fault, i.e. the evaluations that are 
inhibited due to priority a well as the evaluations that 
are running. 



If another evaluation receives a latest evaluated data as 
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"fault", the DF scheduler module 30 inhibits the 
evaluations affected by this other evaluation and so on for 

every evaluation that reports a latest evaluated data as 
"fault" . 



When a specific filtering of the evaluated data as "faults" 
is completed, the controlled data is set to "fault" in the 
related DF module for the remainder of the driving cycle. 
Immediately the controlled data is set to "fault", the 
related DF module sends a request to create DTC-data to the 
data collector module 40. 

Upon the request to create DTC-data, the data collector 
module 40 creates a DTC-block together with an extended 
FRZF and, when finished, sends a request to save this DTC- 

data (with the status "not validated") to the DTC-data area 
module 50. 

On the request to save the DTC-data, the DTC-data area 
module saves the DTC-block together with the extended FRZF 
and, when finished, sends information to the validator 
module 60 that a not-validated DTC-block has been saved, 
and then sends the response that the DTC-block has been 
saved to the data collector module 40. 

When the validator module 60 receives the information 
concerning the saved DTC-block from the DTC-data area 
module 50, it sets up a validator checklist that contains 
all the evaluations that are needed to, on request, respond 
that they have their controlled data as no-fault to the 
validator module before the validator module decides that 
the DTC-block is valid. 

The validator checklist is updated at the end of each 
driving cycle on request sent from the DSM module. 
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When the checklist is completed and the DTC-block is 
decided to be valid, the validator module validates the 
not-validated DTC-block by sending a request to change the 
DTC-block status from not-validated to valid to the DTC- 
data area module 50. 

On request to change DTC-block status from not-validated to 
valid, sent from the validator module 60, the DTC-data area 
module 50 changes the DTC-block status from not-validated 
to valid and, when finished, sends the information that the 
DTC-block is valid to the related DF module. 

When the DF module receives the information that a related 
DTC-block has the status "valid", the DF module initiates 
and controls a DTC store process and, when completed, sends 
a request to change the DTC-block status from valid to 
stored to the DTC-data area module 50 . 

When the DTC-data area module receives the request to 
change DTC-block status from valid to stored from the 
related DF module, the DTC-data area module changes the 
DTC-block status from valid to stored and then sends the 
information signal that the DTC-block has changed status to 
stored to the validator module 60. 



When the validator module receives the information that a 
DTC-block has changed status to stored, it erases the 
related checklist. 

When the DF module receives the information that the 
related DTC-block has the status stored in the DTC-data 
area module, it will, in applicable cases, send a request 
to the MIL handler module 70 to illuminate the MIL. 

When the MIL handler module receives the request to 
illuminate the MIL from the DF module, it illuminates the 
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The above-described creation, saving and status changing of 
DTC-data will also be performed if another DF module sends 
another request to create DTC-data. However, handling of 
the current DTC-data is completed before handling of the 
next one, and so on for every DF module in the diagnostic 
system. In other words, once the DTC-data area module has 
received an acknowledge signal from the validator module 
or, if the current DTC-block status has changed to valid, 
an acknowledge signal from the current DF module, the DTC- 

data area module will handle any new request to save DTC- 
data . 

If the DTC-data area module reports that a further new not- 
validated DTC-block has been saved, the validator module 60 
checks whether the corresponding evaluation to this new 
DTC-block is to be found as an evaluation to be checked in 
the current checklist. If so, then the current checklist 
and associated DTC-block are no longer the possible root 
cause to the fault and the validator module sends a request 
to the data area module to erase the current DTC-block and 
then sets up another checklist for the new DTC-block and so 
on until any DTC-block status is changed to stored in the 
DTC-data area module 50. 



If a DTC-block status has been changed to stored, the 
validator module erases the associated checklist. 

This completes the overall normal operation to inhibit 
affected evaluations and to store the correct DTC, together 
with MIL illumination, in the diagnostic system 40 with one 
or several fault present. 

The present invention is not restricted to the embodiments 
described above and shown in the drawings, but may be 
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varied within the scope of the appended claims. 
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What is claimed is: 

1- A diagnostic system (10), particularly for use in 

an engine management system, for generating a diagnostic 
trouble code ( DTC ) to indicate the operational status of a 
component or sub-system which is being evaluated by said 
diagnostic system, said diagnostic system comprising 

a diagnostic function module (DF module) (20; 20'; 
20 ) for each DTC or a group of related DTCs, said DF 

module including means (22) for executing an evaluation 
routine to evaluate the operational status of a component 
or sub-system to which the DTC of the specific DF module 
relates, and 

a diagnostic function scheduler (DF scheduler) (30) 
for determining which DF module (20; 20'; 20") may be 

allowed to execute an evaluation routine at a particular 
time; 

wherein each DF module comprises 

means (22) for producing a' ranking value dependent 
on the operating status of the component or sub-system 
being evaluated, a ranking value being generated each time 
an evaluation routine is performed; 

means (23) for processing and storing statistical 
results of the ranking values obtained over a number of 
evaluation routines; 

means (22) for evaluating said statistical results 
to produce evaluated data in the form of either an 
evaluated no-fault signal or an evaluated fault signal, and 
means (24) for transmitting said evaluated signals 
to said DF scheduler when a change in said signals occurs. 

2. The system as claimed in claim 1, wherein said DF 

scheduler (30) comprises means responsive to an evaluated 
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fault signal to prevent other DF modules from performing 
evaluations if these other DF modules may be affected by 
said evaluated fault signal. 

3. The system as claimed in claim 1 or 2, wherein said 

DF module (20; 20 ; 20 ) further comprises means (24) for 

comparing said evaluated data with previously generated 
data relating to evaluations of the component or sub-system 
to which the DTC of the specific DF module relates and, in 
the event that an evaluated fault signal is generated, 
comparing said signal with subsequently produced evaluated 
data, to thereby generate either a controlled fault signal 
^ controlled no— fault signal. 

4. The system as claimed in claim 3, wherein said 

system includes a data collector module (40), and said DF 
module comprises means (24) for sending a request to said 
data collector module to create DTC-data when a controlled 
fault signal is generated in said DF module. 

** * The system as claimed in claim 4, wherein said data 

collector module (40) comprises means for creating said 
DTC-data, said DTC-data being in the form of a DTC-block 
containing the DTC and information pertaining to operating 
— conditions -when -said . DTC-was - generated 

6. The system as claimed in claim 5, wherein said data 

collector module (40) comprises means to transmit said DTC- 
block to a validator module (60). 

J " The system as claimed in claim 6, wherein said 

validator module comprises means to determine which 
components or sub-systems the evaluated and subsequently 
generated DTC-block is dependent on, and means to obtain 
data pertaining to the operational status of said 
components or sub-systems on which said controlled 
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fault signal is dependent. 

8. The system as claimed in claim 7, wherein said 
validator module (60) comprises means to evaluate said data 
pertaining to the operational status of said components or 
sub-systems on which said controlled no-fault signal is 

dependent to thereby determine whether said DTC-block is 
valid. 

9. The system as claimed in claim 8, wherein said 
validator module (60) comprises means for changing the DTC- 
block status to valid in the event that the DTC-block is 
determined to be valid, and means for erasing the DTC-block 

in the event that the DTC-block is determined not to be 
valid. 

10. A validator (60) for use in a diagnostic system 
(10), for example in an engine management system, to 
determine the validity of a diagnostic trouble code ( DTC ) 
generated during an evaluation routine within said 
^1^9**ostic system, said validator comprising? 

means for receiving information that DTC-data made 
up of said diagnostic trouble code and data pertaining to 
operating conditions of the engine has been generated? 

means f or establishing a checklist specified by a 

related setup list, said checkup list containing all 
evaluation routines within said diagnostic system that are 
influenced by or have an influence on said DTC; 

means for obtaining data pertaining to the 
operational status of components or systems evaluated 
during said evaluation routines in said checklist, and 

means for checking off from the checklist those 
evaluation routines which are shown to be of controlled no- 
fault status to thereby leave only that evaluation routine 
in which a fault is present. 
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11. A data collector (40) for use in a diagnostic system 
(10), for example in an engine management system, to 
collect and store data in the event that a fault arises in 
a component or sub-system monitored by said diagnostic 
system, said data collector (40) comprising: 

means for receiving a diagnostic trouble code (DTC) 
generated during an evaluation routine, which DTC indicates 
a possible fault in a particular component or sub-system 
evaluated during said evaluation routine: 

means for creating a freeze frame ( FRZF) containing 
operating parameters specific to said DTC by comparing said 
DTC with a FRZF table to obtain a listing of which 
parameters are to be incorporated in said FRZF; 

means for creating an extended freeze frame (FRZF) 
in the form of a history of parameters specific to said DTC 
by comparing said DTC with an extended FRZF table to obtain 

® of which parameters are to be incorporated in 
said extended FRZF, with 

said means for creating an extended freeze frame comprising 
means for obtaining said history of parameters from a 
circular memory in which said parameters are continuously 
recorded, and 

means for combining parameters from said freeze 
frame and said extended freeze frame to produce DTC data. 

12. The data collector as claimed in claim 11, wherein 
said circular memory is in the form of a rotating drum 
(111) upon which said parameters are continuously recorded. 

13. The data collector as claimed in claim 12, wherein 
said rotating drum (111) is divided up into a plurality of 
different time bases (112; 113; 114; 115). 

14. A scheduler (30) for determining the order of 
execution of a plurality of evaluation routines in a 
diagnostic system (10), for example in an engine management 
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system, said scheduler comprising: 

means for receiving a number of requests to run 
evaluation routines; 

means for establishing a priority level for each 
evaluation routine by consulting a scheduler table in which 
each evaluation routine is allocated a priority level; 

means for establishing whether any already run 
evaluation routine has indicated the presence of a fault; 

in the event that the presence of a fault is 
indicated, means for inhibiting any evaluation routine 
which may be affected by the presence of said fault, and 
means for sorting non-inhibited evaluation routines 
into an order or execution based on their priority levels. 

15. The scheduler as claimed in claim 14, wherein said 
means for establishing whether any already run evaluation 
routine has indicated the presence of a fault includes 
means for consulting a scheduler list containing current 
status of evaluation routines in the diagnostic system. 

16. The scheduler as claimed in claim 15, wherein said 
scheduler list contains: 

a listing of all evaluation routines which are 
inhibited? 

a listing of all eval uat ion routines which are 

presently running; 

a listing of all evaluation routines which have 
indicated the presence of a fault, and 

a listing of all evaluation routines which have yet 
to be handled due to presence of faults, elapsed time after 
engine start or priority between the evaluation routines. 

17. A DF module (20; 20'; 20") for executing an 
evaluation routine during an operating cycle of electro- 
mechanical equipment to detect a fault in a component or 
sub-system of said equipment and to generate a diagnostic 
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trouble code (DTC) to indicate the operational status of 
said component or sub-system, said DF module comprising 

means (22) for executing an evaluation routine to 
evaluate the operational status of said component or sub- 
system to which the DTC of the specific DF module relates, 
means (22) for producing a ranking value dependent 
on the operating status of the component or sub-system 
being evaluated, a ranking value being generated each time 
an evaluation routine is performed; 

means (23) for processing and storing statistical 
results of the ranking values obtained over a number of 
evaluation routines; 

means (22) for evaluating said statistical results 
to produce evaluated data in the form of either an 
evaluated no-fault signal or an evaluated fault signal; 

means (24) for receiving said evaluated signals from 
said means (22) for evaluating said statistical results to- 
produce a controlled fault signal upon receipt of a 
predetermined number of evaluated fault signals; 

means (25) for deciding whether to store said 
controlled fault signal in the form of DTC-data for the 
remainder* of the driving cycle; 

means (25) for determining whether to erase any 
stored DTC-data, and 

means — ( 25.).. .for., deciding -whether -to -illuminate— or - 

extinguish a malfunction indication lamp dependent on the 
stored DTC-data. 
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DTC-Block. 



m 






i. 


DTC. 


2 bytes. 


2. 


DTC-Block Status. 


At minimum 3 bits. 




Latest DTC-Subcode. 


2 bytes. 


KB 


Initial DTC-Subcode. 


2 bytes. 


5- 


FRZF Delay Time. 


Implementation spec. 




Time Stamp (or No of WUCs since Reset of DTCs). 


Parameter specific. 


B 


Time After Engine Start. 


Parameter specific. 


8. 


Ambient Air Temp. 


Parameter specific. 


9. 


Ambient Air Pressure. . 


Parameter specific. 


10. 


Vehicle Speed. * 


Parameter specific. 


11. 


Engine Speed. * 


Parameter specific. 


12. 


1 Engine Load. * 


Parameter specific. 


13. 


Engine Coolant Temperature. * 


Parameter specific. 


14. 


Fuel Trim. * 


Parameter specific. 


15. 


System Status Register. (*) 


3 bytes. 


16. 


DTC Specific Parameter 1 . 


2 bytes. 


17. 


DTC Specific Parameter 2. 


2 bytes. 


18. 


DTC Specific Parameter 3. 


2 bytes. 


19. 


DTC Specific Parameter 4. 


2 bytes. 


20. 


Pointer To The Corresponding Extended FRZF. 


Implementation spec. 



FIG. 6 
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